Hello Factorio players, lets start our developer to player interaction right now! :)
Hello, as the team is getting slowly bigger and we still don't have any dedicated project manager, we had to start looking for tools to help us manage the team. We are testing software that allows our team members to track time spent on individual tasks, so right now my timer on "Friday facts related work" is running. I hope it to give me better insight into what kind of tasks our time goes to, where are we losing most of it, or what were the people doing when I was not here. People tend to not like these kind of changes, but we just have to admit that we are not the 4 people punk development team working from our living room and we need to invest more time into working efficiently.
Further optimisations I finished the item stack optimisations mentioned in FFF-198, and was able to do some performance tests. First I tested how many stacks on a big map actually need to use an externally allocated object (Item), and how many of them are plain. On the huge map I tested, it turned out that only 36K out of 1M stacks need the Item object. These were mainly science packs, as they need it for the progress of how used-up they are (and now when I think about it, it could also be omitted by only using the objects for science packs that are partially used up already). Overall factory performance was increased approximately 2% by this. It is nothing huge, but every bit matters. One of the programmer that has read access to the code (Zulan), came up with a pull request that improves performance in Factorio by prefetching memory in the update loops ahead. The problem when normally updating objects is, that CPU asks for memory representing the object. The memory is slow, at least compared to the CPU cache or the CPU speed. The memory transfer speed itself is not that slow, but the waiting (latency) time between ordering and receiving it is. This means, that what very often happens is, that CPU orders data of next entity from the memory, then it waits for quite a long time to get it, and then it does its logic. The memory prefetching partially solves it by doing this: Order data of the next entity from memory (prefetch) Do the logic of the current entity in the meantime Go back to start The overall measured performance improvements vary between 9-12%, which is certainly a nice addition.
I decided to write about the results of the item stack optimisations explained in the FFF-198, so I rushed today to finish its implementation, just to find out that the task affects an even bigger part of the code than I expected, Items are related to many things in Factorio :) After many hours of rewriting and fixing, I can compile it and even start a game, but most of the things are broken. It is quite funny to see some of the basic item interactions to be broken. Now I'm making commits like "Now I can split stacks", "Now I can merge stacks", etc. It reminds me the old days. In conclusion, the details of the optimization will have to wait for next week, and since it is after 10pm, this Friday facts will be somewhat shorter :)
Hello, the 0.15 has been declared stable. Unfortunately we found some smaller problems, so there is going to be at least one bugfix release. One of the problems we discovered yesterday, is a glitch in the blueprint transferring logic that results in the transfers stopping forever when a player that is just transferring his blueprint into the game leaves. I'm quite surprised that I found it out myself when I was testing something else, and we didn't have a single bug report regarding it.
Hello, I can't believe that we have been able to produce a post every Friday for 200 weeks without missing a single one. To be honest I'm not sure if this isn't the right time to pause for a while, to avoid being this kind of show that gets worse and worse over time until it is so bad that you want to take your intestines and strangle yourself with them. But people in the office convinced me with arguments like "FFF is the only good thing we have", so we probably have to continue for a little longer.
Hello, version 0.15.30 was released today, and we consider it to be our first 0.15 stable version candidate, as long as no other big bugs appear, we will have 0.15 stable in a week. As the teasing never ends, it is time to show some ongoing work on 0.16 already.
Hello, after weeks and weeks of going through bug reports and fixing stuff (after all 0.15 was one of our biggest releases), it seems that we are approaching the end of 0.15 stabilisation. The (wishful) plan is to have a stable candidate for 0.15 next week. Sadly, this will change our attention to just different category of bugs: Those that we plan to fix for the 0.16 as they are not so critical and the changes required to fix them are too big to be done in 0.15 at this point.
Hello, we try to fix bugs as fast as we can, the more we fix, the more get reported, it will takes weeks to get to stable version ... blah blah blah
